Manual Trigger. Allows the automation to be run on demand rather than in response to a schedule or event. Extremely useful for testing as it allows sample JSON messages to be passed downstream.After completing this lesson, you’ll be able to:
Automations are built using a drag-and-drop interface similar to FME Workbench. Your Automations can consist of the following components:
Manual Trigger. Allows the automation to be run on demand rather than in response to a schedule or event. Extremely useful for testing as it allows sample JSON messages to be passed downstream.
Triggers. A Trigger listens for and receives messages from an external client or from within FME Flow. Every automation begins with a Trigger.
Actions. Process messages from a trigger with an FME workspace or other tool hosted on Flow.
External Actions. Sends a message to an external client or another process in FME Flow. What happens afterward is no longer part of this Automation.
Split-Merge Block. Combines messages from multiple workspace actions. The message includes content from workspaces that run a single job, or multiple jobs, depending on the input message and workspace behavior.
Annotations. Add annotations to the automation canvas just like FME Workbench which can be stand-alone or attached to components.
Bookmarks. Organizes your workflow by grouping and separating components.
For a full description of triggers and actions available, please visit the Automations documentation.
Let's look at the different components of an Automation in more detail.
A client is a user or system that sends or receives a message to/from FME Flow. The client may be a physical person or may just be a component in a computer system. Either way, the majority of the time, a client is not a core part of FME Flow, rather someone or something that interacts with it. There are two trigger protocol exceptions to this (Schedules and System Events) whereby FME Flow is also the client sending the message.
For example, a database update might cause a trigger to send a notification to FME Flow, in which case the database system is the client. However, a client could also be a person who, for example, triggers a notification by sending an email to FME Flow.
Likewise, FME Flow can send a notification for another client system. Alternatively, this client can also be a real person, who might receive a notification in the form of an email.
A trigger is an FME Flow component that receives incoming notifications from a client.
To set up a trigger in FME Flow, a workspace author (or administrator) must create a new Automation. You can create an Automation in the FME Flow Web Interface on the Automations > Build Automation page:
Some common Triggers in FME Flow Automations include:
An action is an FME Flow component that sends outgoing notifications to a client.
To send a notification in FME Flow, a workspace author (or administrator) must first create an Automation that contains a trigger, the output of this node is then connected to the action - just like how you connect transformers in FME Workbench.
Similar to the FME Workbench canvas, Automations are constructed in a user-friendly drag-and-drop interface. Triggers and actions are displayed on the canvas as nodes identifiable by their different color. Input and output ports are used to create connections that will pass messages from the trigger to the associated action. The user must configure a series of parameters for the Automation to succeed depending on the protocol.
Internal actions in FME Flow Automations include:
Some common External Actions include:
A protocol is a system of data exchange between FME Flow and a client.
We know that FME sends and receives messages. Protocols are the method by which these messages are sent and received. Each Trigger and Action is defined using a particular communication protocol.
To trigger an incoming message by email – for example – you would create an Automation using an Email - SMTP Trigger. To send a notification to a Java Message Service, you would create an Automation that contains a JMS Message Action.
There are many different protocols available in FME Flow; some of them are only for use as a Trigger, others are only available as Actions, and some of them can be used with both types.
This table lists the different Trigger and Action protocols and the following pages go into greater detail on some of the most commonly used types.
| Protocol | Description | Trigger | Action |
|---|---|---|---|
| Amazon S3 | Monitoring activity in an AWS S3 bucket/Communication to Amazon’s Simple Storage Service | Y | Y |
| Amazon SNS | Communication with Amazon’s Simple Notification Service | Y | Y |
| Amazon SQS | Communication with Amazon’s Simple Queue Service | Y | Y |
| Azure Event Grid | Communication with Microsoft Azure Events | Y | Y |
| Dropbox | Monitoring activity in a Dropbox folder/Communication of a notification (file) to the Dropbox web service | Y | Y |
| Email (IMAP) | Receive email messages from an IMAP Server | Y | |
| Email (SMTP) | FME Flow itself receives email messages/Communication via an email server | Y | Y |
| Filter | Test incoming messages for the presence of a specified string | Y | |
| FME Flow Topic | Receive/Send messages to a Topic to initiate workflow processes | Y | Y |
| FME Workspace | Run an FME Form Workspace published to FME Flow | Y | |
| FME Dynamic Workspace | Run an FME Form Workspace published to FME Flow, with the repository and workspace name coming from output keys in the Automation | Y | |
| FTP Directory | Monitor activity/upload a file to an FTP Site | Y | Y |
| HTTP Request | Post HTTP requests to the specified URL | Y | |
| JMS | Communication with a Java Message Service | Y | Y |
| Log | Write Event/Automation details to a log | Y | |
| Merge | Combine messages before proceeding downstream in an Automation | Y | |
| Resource or Network Directory | Monitor activity in a resource location or network directory | Y | |
| SFTP Directory | Communication with an SFTP site | Y | |
| Schedule | Complete workflow tasks at specific times in the future | Y | |
| System Events | Communication with FME Flow systems | Y | |
| UDP | Communication via a User Datagram Protocol port | Y | |
| WebSocket | Communication via a WebSocket channel | Y | Y |
| Webhook | Receive messages sent as HTTP Post requests from another application | Y |
For a complete list of triggers and actions available in FME Flow Automations and how to configure them, see our documentation.
Protocols are pre-defined components in the FME Flow architecture and do not need to be defined in the web interface.
However, a number of fields are made available to configure when an Automation is created.
For example, here are the parameters for a Resource or Network Directory (updated) Trigger:
You must set these parameters when the Automation is created as they are needed for FME to watch and receive notifications about this Directory. If you don't configure these parameters, the Automation will not behave as anticipated when you enable it.
